A variety of tools and methods exist for generating and displaying reports. For instance, one commonly used application for generating reports, particularly in a business intelligence context, is a report generating application referred to as Crystal Reports. Crystal Reports is a software application available from SAP AG that can be used to design and generate reports by pulling data from a wide range of data sources.
Typically, when a business entity uses a report generating application, such as Crystal Reports, the application includes a set of original or master reports, or more precisely, master report definitions. A report definition is a file that specifies the format and source of data to be included in a particular report. Accordingly, the report generating application utilizes the report definition to generate an instance or version of a particular report. Many conventional report generating applications include features, or come with separate applications, that allow for a user to customize a master report definition to generate customized report definitions. Customized report definitions can be defined to enhance or replace the master reports, and are generally useful for displaying the specific data that is applicable to the nature of the particular business entity.
Each report, whether a master report or a customized report, typically contains a set of fields that are displayed as columns in a table format. Oftentimes users only want to view a report with a subset of the columns of the original report, and this is achieved through the process of report personalization. Traditionally, personalizing a report has been achieved through the same, or a very similar, process as is used for customizing a report. For instance, when personalizing a report, the user modifies the definition of an original report (e.g., a master or customized report definition) by removing the columns and column headings that the user does not want displayed on the report. The user may also need to manually move the remaining columns and column headings in order to fill in the blank space left by the removed columns. The user then saves a copy of the modified report, and then generates an instance of the modified report for viewing.
A variety of problems exist with the way in which reports are personalized using conventional report generating applications, such as Crystal Reports. One issue with the current methods of report personalization is that each user has to have both the skills and permissions (e.g., file access permissions) to modify a report definition for each original (e.g., default or customized) report. Typically, a large number of users may have permission to generate and view a report, but it is not always the case that those users will have permission to modify or personalize the report definition for the report. Furthermore, not all users will have working knowledge of the report design tools, features and user interfaces that are used to modify or personalize a report definition.
Typically, when a report is personalized, the modified report definition is saved as a new report definition, independent of the original. This is problematic for a number of reasons. First, managing the reports (specifically, the report definitions) becomes a hassle as multiple personalized reports with similar names may be generated, making it difficult for a user to determine which report is the correct report. Additionally, because a personalized report definition is independent of the original report definition from which it was generated, any changes made to the original do not carry over or flow through to the personalized report definition. For instance, if the original report definition is modified such that in the modified report definition, data is selected from a different data source than in the original report definition, or a field is formatted differently, the modification will not flow through to the personalized report definition. Consequently, with conventional report generating applications, to keep a personalized report in unison with its original counterpart, a user may be forced to periodically update the personalized report definition to reflect any changes made to the original report definition.
Another issue that frequently arises with conventional report generating applications involves user inputs—referred to herein as report parameters—that are required to generate an instance of a report. Often, when a user wants to generate a report, the user will be prompted to provide one or more report parameters (e.g., a date range) before the user can generate and view the report. Traditionally, these report parameter values have to be entered by the user every time the user logs in to the report generating application or service and generates an instance of the report to view. Often, the report parameter values do not change between user sessions. Consequently, the user is forced to perform a tedious data entry process to fill in the report parameter values each time the user generates and views the report. This is especially inconvenient when the report definition requires that many report parameters be specified in order to generate an instance of the report.